You mix stuff in the PRs which make them difficult to accept.

Can you reference which timeout calculation bug you are referring too?

You mix stuff in the PRs which make them difficult to accept.

The other changes are somewhat related to the primary fix.

Can you reference which timeout calculation bug you are referring too?

The main issue is with this code:

Where the if (timeout >= 0) check is done against a recomputed timeout instead of the timeout originally passed to the function. The recomputed timeout additionally appears to result in inconsistent behavior when exactly 0 since QMUX requests appear to have special cased behavior for timeouts of zero here(and in a few other places I think):

I understand you are referring to issue #414 - we don't need nano precision and excessive object reaction to fix that.

In addition, your fix doesn't address the real intent of using a 0 timeout, which is fire-and-forget the message. In addition, this fix only fixes the synchronous call to MUX.request, not the async one.

I addressed this issue in 4cd6c95 - we can raise a case for the monotonic clock stuff separately.

I understand you are referring to issue #414 - we don't need nano precision

Reason for using System.nanoTime() isn't precision related but rather due to System.currentTimeMillis() being unsafe for elapsed time calculations due to using the wrong type of clock. Note on Linux System.nanoTime() calls are actually faster than System.currentTimeMillis() calls.

excessive object reaction to fix that.

There is some overhead from this but it seems to be minimal from some benchmarks I did, we could technically avoid it but not sure that would be worth it.

In addition, your fix doesn't address the real intent of using a 0 timeout, which is fire-and-forget the message. In addition, this fix only fixes the synchronous call to MUX.request, not the async one.

Hmm, the async version still doesn't really look right to me. Reworked some of the logic here more in #425.